Run-Time Symbol Resolution

Run-Time Symbol Resolution

Dynamically linked executables can contain symbol references that aren't resolved before run time. Any symbol references in your main program or in an archive must be resolved at link time, unless you specify the -ignore_unresolved argument to cc. DSOs may contain references that aren't resolved at link time. All data symbols must be resolved at run time. If rld finds an unresolvable data symbol at run time, it will cause the executable to exit with an error. Text symbols are resolved only when they're used, so a program can run with unresolved text symbols, as long as the unresolved symbols aren't used.

You can force rld to resolve text symbols at run time by setting the environment variable LD_BIND_NOW. If unresolvable text symbols exist in your executable and LD_BIND_NOW is set, the executable will exit with an error, just as if there were unresolvable data symbols.

Compiling with -Bsymbolic

When you compile a DSO with -Bsymbolic, the dynamic linker resolves referenced symbols from itself first. If the shared object fails to supply the referenced symbol, then the dynamic linker searches the executable file and other shared objects.

For example:

main--defines x
x.so--defines and uses x

If you compile x.so with -Bsymbolic on, the linker tries to resolve the use of x by looking first for the definition in x.so and then by looking in main.

In FORTRAN programs, the linker allocates space for COMMON symbols and the compiler allocates space for BLOCK DATA. The first kind of symbol (with COMMON blocks present) appears in the symbol table as SHN_MIPS_ACOMMON (uninitialized DATA) whereas the second kind of symbol (with BLOCK DATA present) appears as SHN_DATA (initialized DATA). In general, initialized data takes precedence when the dynamic linker tries to resolve a symbol. However, with -Bsymbolic, whatever is defined in the current object takes precedence, whether it is initialized or uninitialized.

Variables that are declared at file scope in C with -cckr are also treated this way. For example:

int foo[100];

is COMMON if -cckr is used and DATA if -xansi or -ansi is used.

For example:

In main:

COMMON i, j /* definition of i, j with initial values */
DATA i/1/, j/1/
CALL junk
END

In x.so:

SUBROUTINE junk
COMMON i, j
/* definition of i, j with NO initial values */
/* initialized by kernel to all zeros */
PRINT *, i, j
END

When you build x.so using -Bsymbolic, this program prints 0 0.
When you build x.so without -Bsymbolic, the program prints 1 1.

Converting Libraries to DSOs

When you link a program with a DSO, all of the symbols in the DSO become associated with the executable. This can cause unexpected results if archives that contain unresolved externals are converted to DSOs. When linking with a PIC archive, the linker links in only those object files that satisfy unresolved references.

If an object file in an archive contains an unresolved external reference, the linker tries to resolve the reference only when that object file is linked in to your program. In contrast, a DSO containing an external data reference that cannot be resolved at run time causes the program to fail. Therefore, use caution when converting archives with external data references to DSOs.

For example, suppose you have an archive, mylib.a, and one of the object files in the archive, has_extern.o, references an external variable, foo. As long as your program doesn't reference any symbols in has_extern.o, the program will link and run properly. If your program references a symbol in has_extern.o and doesn't define foo, then the link will fail. However, if you convert mylib.a to a DSO, then any program that uses the DSO and doesn't define foo will fail at run time, regardless of whether the program references any symbols from has_extern.o.

Two possible solutions exist for this problem.

Add a "dummy" definition of the data to the DSO. A data definition appearing in the main executable preempts one appearing in the DSO itself. This may, however, be misleading for executables that use the portion of the DSO that needs the data, but that failed to define it in the main program.
Separate the routines that use the data definition into a second DSO, and place dummy functions for them in the first DSO. The second DSO can then be loaded dynamically the first time any of the dummy functions is accessed. Each of the dummy functions must verify that the second DSO was loaded before calling the real function (which must have a unique name). This way, programs run whether or not they supply the missing external data, as long as they don't call any of the functions that require the data. The first time one of the dummy functions is called, it tries to dynamically load the second DSO. Programs that do not supply the missing data fail at this point.

For more information on dynamic loading, see "Dynamic Loading Under Program Control" below.